The increasing complexity of System-on-a-Chip (SOC) devices and the simultaneous demand for a reduction in the cost of chip testing has forced both integrated circuit (IC) manufacturers and tester vendors to rethink how IC testing should be performed. According to industry studies, without re-engineering the projected cost of testers will continue to rise dramatically in the near future.
A major reason for the high cost of test equipment is the specialized nature of conventional tester architecture. Each tester manufacturer has a number of tester platforms that are not only incompatible across companies such as Advantest, Teradyne and Agilent, but also incompatible across platforms within a company, such as the T3300, T5500 and T6600 series testers manufactured by Advantest. Because of these incompatibilities, each tester requires its own specialized hardware and software components, and these specialized hardware and software components cannot be used on other testers. In addition, a significant effort is required to port a test program from one tester to another, and to develop third party solutions. Even when a third party solution is developed for a platform, it cannot be ported or reused on a different platform. The translation process from one platform to another is generally complex and error prone, resulting in additional effort, time and increased test cost.
In such specialized tester architecture, tester software such as the operating system and test analysis tools/applications run on a host computer. Due to the dedicated nature of the architecture, all hardware and software remain in a fixed configuration for a given tester. To test a hardware device or an IC, a dedicated test program is developed that uses some or all of the tester capabilities to define the test data, signals, waveforms, and current and voltage levels, as well as to collect the device under test (DUT) response and to determine DUT pass/fail.
The testing of a wide variety of DUTs requires the hardware and software components of the tester system to exercise a wide range of functionalities and operations. During testing, different sets of vendor-supplied test modules may be utilized to support the wide range of functionalities, and the test system needs to be configured to support the vendor-supplied test modules and their corresponding calibration and/or diagnostics data in a plug-and-play manner. When a new vendor-supplied test module is utilized, calibration and/or diagnostics of the new test module may be required. In addition, the performance of a test module may be drifted outside the original calibrated range overtime, and the test module may need to be re-calibrated or re-diagnosed by the test system.
Hence, there is a need for open architecture test systems that can be configured with different test modules based on testing requirements. Specifically, there is a need for open architecture test systems that can be configured to use vendor-supplied calibration and/or diagnostics (C&D) information in a plug-and-play manner during runtime.